PATENT APLiCATION 
Attorney Docket No. XERZ 200396 
A0773-US-NP 

EXHIBIT A 

IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

INVENTOR(S) Chien-Sheng Chou et al. 

TITLE REMOTE ORDER ENTRY SYSTEM 

AND METHOD 

APPLICATION NO. 09/750,635 

FILED : 28 December 2000 

CONFIRMATION NO. 6973 

EXAMINER Douglas B. Blair 

ART UNIT 2142 

LAST OFFICE ACTION 10 August 2005 

ATTORNEY DOCKET NO. A0773-US-NP 

XERZ 2 00396 

Commissioner for Patents 

P.O. Box 1450 

Alexandria, VA 22313-1450 

DECLARATION UNDER 37 C.F.R. §1.131 

Dear Sir: 

As a person signing below: 

1. We, Chien-Sheng Chou, Charles G. Kanzinger and Qing Zhang are the co- 
inventors of claims 1-7, 9-19 and 21-23 of the above-identified patent application. 

2. We have read and are familiar with U.S. Patent No. 6,920,430, issued to 
Robert M. Berton, et al. on July 19, 2005, and filed at the USPTO on September 22, 2000. 

3. We hereby declare that at a date at least prior to September 22, 2000, we 
had completed the invention, as described and claimed in the subject patent application, in 
this country, the United States of America. In this regard, we have attached Exhibit 1 as 
evidence of completion of the invention prior to September 22, 2000. We hereby declare 
and say the relevant portions of Exhibit 1 were prepared at least prior to September 22, 
2000. 
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4. Specifically, the redacted copy of Exhibit 1, attached hereto, provides 
evidence the claimed subject matter of the above-referenced patent application and 
Amendment submitted April 7, 2005 was completed prior to September 22, 2000. 

Regarding Exhibit 1 , Statement of Work for Internet WebREQ (iWebReqs): 
This document provided the initial disclosure of the above-referenced patent application 
subject matter. 

This exhibit discloses a system and method as recited in claims 1-7, 9-19 and 
21-23 for generating a requisition for user selectable inventory items comprising a client 
system connected to a network; a server computer system connected to the network, the 
network interconnecting the client computer system and the server computer system, the 
client computer configured to allow a plurality of users to access the server computer 
system, the server computer system configured to associate one or more of a plurality of 
work sites with each of said users, each worksite defining a group of users; associate 
inventory items with one or more of a plurality of work sites using a validation rules 
database associating each of said user selectable items with one or more of a plurality of 
work sites with which a user must be associated to verify the user requested inventory item 
for a requisition; identify associated inventory items which may be requisitioned by a user 
associated with the one or more associated work sites, and identify associated inventory 
items which may not be requisitioned by a user associated with the one or more associated 
work sites; receive and process a request for one or more user selected inventory items; 
verify that each user requested inventory item is an item associated with the user's one or 
more associated work sites; and generate a requisition for the verified user requested 
inventory items. 

5. Each of the dates deleted from Exhibit 1 is a date at least prior to September 
22, 2000. 

6. It is submitted that the information in Exhibit 1 demonstrates the applicants' 
invention of a Remote Order Entry System and Method was completed in this country at 
least prior to September 22, 2000. 

We hereby declare that all statements made herein of our own knowledge are true 
and that all statements made on information and belief are believed to be true, and further 
that these statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 
18 of the United States Code, and that such willful false statements may jeopardize the 
validity of the application or any patent issued thereon. 
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4. Specifically, the redacted copy of Exhibit 1, attached hereto, provides 
evidence the claimed subject matter of the above-referenced patent application and 
Amendment submitted April 7, 2005 was completed prior to September 22, 2000. 

Regarding Exhibit 1, Statement of Work for Internet WebREQ (iWebReqs): 
This document provided the initial disclosure of the above-referenced patent application 
subject matter. 

This exhibit discloses a system and method as recited in claims 1-7,9-19 and 
21-23 for generating a requisition for user selectable inventory items comprising a client 
system connected to a network; a server computer system connected to the network, the 
network interconnecting the client computer system and the server computer system, the 
client computer configured to allow a plurality of users to access the server computer 
system, the server computer system configured to associate one or more of a plurality of 
work sites with each of said users, each worksite defining a group of users; associate 
inventory items with one or more of a plurality of work sites using a validation rules 
database associating each of said user selectable items with one or more of a plurality of 
work sites with which a user must be associated to verify the user requested inventory item 
for a requisition; identify associated inventory items which may be requisitioned by a user 
associated with the one or more associated work sites, and identify associated inventory 
items which may not be requisitioned by a user associated with the one or more associated 
work sites; receive and process a request for one or more user selected inventory items; 
verify that each user requested inventory item is an item associated with the user's one or 
more associated work sites; and generate a requisition for the verified user requested 
inventory items. 

5. Each of the dates deleted from Exhibit 1 is a date at least prior to September 
22, 2000. 

6. It is submitted that the information in Exhibit 1 demonstrates the applicants' 
invention of a Remote Order Entry System and Method was completed in this country at 
least prior to September 22, 2000. 

We hereby declare that all statements made herein of our own knowledge are true 
and that all statements made on information and belief are believed to be true, and further 
that these statements were made with the knowledge that willful false statements and the 
like so made are punishable by fine or imprisonment, or both, under Section 1 001 of Title 
18 of the United States Code, and that such willful false statements may jeopardize the 
validity of the application or any patent issued thereon. 
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1. Description: 



This project involves developing a remote order entry application that will allow 
Spectrum Plus remote users to enter requisitions and inquire the status of their 
requisitions and items using the Internet/intranet. 

2. Project Goals: 

Offer clients an Internet/intranet requisitioning application providing simple requisition 
entry (wizard style and the "shopping cart" format that already exists many places on the 
web), easy search and inquiry, and on-line image/form viewing capabilities. 

3. Customers: 

Bradley Company customers who want to put Remote Order/Requisition Entry system on 
the Internet/intranet for their remote users/requesters. 

The following customers have been contacted to collect and verify the requirements: 




4. Commitments and Dependencies: 

Reference Software development plan that applies to content 5793. 



5. System Environments: 

This Internet/intranet application will run on a Microsoft platform. Customers require an 
existing company website with at least one web server running Microsoft Windows NT 
and Internet Information Server (IIS) 4.0 or above. 

The Application Business Components and Data Access Components will be hosted on a 
Microsoft Transaction Server (MTS) 2.0 or above. This MTS Server can reside on the 
same machine as the web server or can be separated on a standalone NT Server machine. 

This Internet/intranet application will use the existing Spectrum Plus database. 
(Microsoft SQL Server 6.5/7.0, Oracle 7.3 or above, or Sybase Adaptive Server 1 1 or 
above). 
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Local Users will access this application via the company's intranet using Microsoft 
Internet Explorer 4.01 5 5.0, or higher. Remote Users will access this application via the 
Internet through the company ! s website using Microsoft Internet Explorer 4.01, 5.0, or 
higher. Netscape browsers (Navigator or Communicator) will be supported in the 
immediate future release, if required by customers. Users need to install the Adobe 
Acrobat browser plug-in in order to view images/forms on-line. 

6. Roles and Responsibilities: 

Design: 



Development: 



7. Key Milestones: 

Reference Software development plan that applies to content 5793. 

8. Requirements: 

1. General: 

1.1. This application will be opened/linked from an existing customer company website. 

1 .2. The web page logo can be customized to use the customer's company logo. 

1 .3. Users will see the login page and will login as a Spectrum Plus Site User. 

1 A The User ID and Password can be passed from customer's other application to the 
application Login Page to bypass the Login Page. If it failed to pass the login 
validation, the Login Page will be displayed. 

1 .5. This application has the following functions: 



o Requisition Entry 

o Requisition Inquiry 

o Item Inquiry 

o Update Requester Information 

o Change Working Site 

o Logout and re-login 




Quality: 



Support/Implementation 





Training: 
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o On-line Image/Form Viewing (for PDF images only) 

1.5. The Administrator can set up Site configuration from the Spectrum Plus Site Setup 

window using new settings that allow the Item Inquiry, Requisition Inquiry, Item 
Search, Image Viewing, and Update Requester Information functions to be turned 
on or off. 

1 .6. Each User has to be set up as an individual requester. This is because each 

requester will own his/her Requisition Shopping Cart at all times. 

2. Requisition Entry: 

2.1 . Access to items is determined based on the Site's State/Code validation rules. This 

access restriction applies to searching for items and adding items to the 
Requisition Shopping Cart. 

2.2. The requester can click on a "View" button next to the Item ID to view the PDF 

image, if it is available. 

2.3. The Requisition Shopping Cart will store items in the database for the requester, 

hence the requester can log in and out of the application without losing and re- 
entering items. 

2.4. When the requester adds Item(s) to the Requisition Shopping Cart, the standard 

"NetLink" validation rules will be applied and the corresponding messages will 
be displayed if the Item failed the validation rules and cannot be added to the 
Cart. 

2.5. The Requisition Quantity can be changed in the Requisition Shopping Cart. 

2.6. The requester can remove item from the Requisition Shopping Cart or "reset" 

(empty) the entire Requisition Shopping Cart. 

2.7. The requester does not need to enter any requisition information (i.e., Requisition 

Header, Shipping Address, and Account Codes) until they decide to proceed with 
generating a requisition for all of the items in their Requisition Shopping Cart. 

2.8. The requester will navigate through wizard style pages to enter or review the 

requisition information. 

2.9. The Site ID determines the Ship To Address and Account Code information that 

default into the respective fields. However, if the user's Requester ID has a 
default Ship To Address and/or default Account Codes set up in the Spectrum 
Plus Person Setup window, the user's default information will be used in the 
requisition pages. 

2.10. After going through the wizard to enter or review requisition information, the 

requester will see a summary page before committing to create and save the entire 
requisition. The requester can navigate backward to change any information or 
add/delete item(s) from the Requisition Shopping Cart. 

2.1 1 . A new Requisition Number will not be generated and the requisition will not be 

saved until the requester clicks the "Complete Requisition" button on the 
Requisition Summary page. 

2.12. When the requester clicks on the "Complete Requisition" button, all items in the 

Requisition Shopping Cart will need to be validated again to identify items that 
have been stored in the Cart for a long period of time and have become invalid. 

2.13. When the requester clicks on the "Complete Requisition" button, a confirmation 

page with the entire requisition information (i.e. Requisition Number, Requisition 
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Header, Requester Shipping Address, Account Codes, and Items) will be 
generated. The requester can print this page as a hardcopy record. 

2.14. Once the requisition has been generated, the Requisition Shopping Cart for the 

requester will be emptied (the corresponding data is deleted from the database). 

2.15. In the first release, there will be no function to retrieve existing requisitions in order 

to make changes or to copy a requisition. Requisition Entry will be strictly for 
entering new requisitions. 

2. 16. In the first release, there will be no "Dynamic Kit" function. The requester will not 

be able to add any "Dynamic Kit" ID to the Requisition Shopping Cart. 

2.17. The requester can add "Standard Kit" ID to the Requisition Shopping Cart. Pick 

Ticket and Kit Server will take over the process after the requisition is saved. 

2.18. There will be no "Serial Number" function in the first release. 

2.19. There will be no "PrintLink One Time Job" function in the first release. 

2.20. There will be no "Credit Return" function in this application. 

3. Requisition Inquiry: 

3.1. Users will retrieve requisitions using the criteria: 

o Requisition Number, (no search available) 

o Requester ID (drop-down, showing only the requesters associated with the 

current Site), 
o Date Range on requisition date, 
o Header Status (All, Open, Closed, Partial). 

3 .2. Users will only be able to retrieve requisitions entered from the Site. 

3 .3 . Users can view information on: 

o Requisition Header, 

o Ship-to Address, 

o Header Account Codes, 

o Requisition Items, 

o Requisition Item Account Codes, 

o Disbursement. 



4. Item Inquiry: . . 

4. 1 . Users will retrieve items using only one of the following fields in the criteria: 

o Item ID (partial match), 

o Description (partial match), 

o Commodity (drop-down, exact match), 

o Coordinator ID (drop-down, exact match), and 

o Item User Field 1 -4 (partial match). 

4.2. Only items that match the entered criteria and have valid states and codes for the 

current site will be retrieved. 

4.3 . Each item on the search result page will have a hyperlink on the Item ID field to 
open a detail Item Information Page. 

4.4. Only basic Item information (Item Main tab) will be displayed in the first release. 

4.5. Customers will be able to customize the Item Information page to display 
information of their need in the future release. 

4.6. Users can add retrieved items to their Requisition Shopping Cart. 
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4.7. Users can view an item's image by clicking on a "View" button next the.Item ID. 



5. Update Requester Information: 

5.1. Requesters can update their own personal information such as: 
o Person Name, 
o E-mail Address, 

o Default Ship-to Address and Phone Number, and 
o Default Account Codes. 

6. Change Working Site: 

6. 1 . Users can click a button to go to the Site Selection page to change the Working Site. 

7. Logout and re-login: 

7.1. Users can click on a button to log out of the application and go directly to the 
"Login" page. 

8. On-line Image/Form Viewing: 

8. 1 . There will be a "View" button next to every Item ID when a PDF image is available 



9. Diagnostics 

Diagnostic Procedures will be provided for customers or Bradley Implementation team to 
ensure the communication between all layers (i.e. from Presentation Layer to Business 
Layer, from Business Layer to Data Access Layer, and from Data Access Layer to 
Database). 

10. Development: 

Bradley Company Development team will be assigned the project to develop this 
iWebReqs feature. 

11. Quality: 

Bradley Company Quality team will be assigned the project to ensure quality in the 
iWebReqs feature. 

12. Implementation: 

Reference Software development plan that applies to content 5793. 
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13. Risks and Mitigation. 

Reference Software development plan that applies to content 5793. 

14. Assumptions: 

Reference Software development plan that applies to content 5793. 

15. Estimates: 

Reference content 5793. 



16. Revision History: 



Version 



No. 



Date 



Description or Purpose of Changes 



1.0 



Initial Creation 
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Actor (s): 

□ Requester 

Use Cases: 

□ Log into the system 

□ Login Using Shared Account 

□ Select a Working Site 

□ Change the Working Site 

□ Display the Requisition Cart 

□ Search for an Item 

□ Item Validation - Item Accessibility 

□ Display Item Detail Information 

□ Get Image Link 

□ View an Image/Form 

□ Add Item to the Cart 

□ Item Validation - Item Status 

□ Delete Item from the Cart 

□ Empty the Cart 

□ Generate a Requisition 

□ Search for a Requisition 

□ Modify Requester information 

□ Change Requester 

□ Log out of the system 

Business Objects: 

a User 

□ Requester 

□ Site 

□ Item 

□ ItemSearch 

□ ItemValidationAccessibility 

□ ItemValidationAccessibilityCustom 

□ ItemValidationStatus 

□ ItemValidationStatusCustom 

□ REQCart 

□ Requisition 

□ AccountCode 

□ Address 

□ REQSearch 

□ Code 
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□ Sequence 

□ BCApplication 

User Interfaces: 

□ Login (Figure 1) 

□ About (Figure 2) 

□ Change Site (Figure 3) 

□ Help Menu (Figure 4) 

□ Update Requester Information (Figure 5) 

□ Requisition Cart (Figure 6) 

□ Item Search Criteria (Figure 7) 

□ Item Search Result (Figure 8) 

□ Item Information (Figure 9) 

□ View Image (Figure 10) 

□ Item Revision (Figure 11) 

q Requisition Header (Figure 12) 

□ Requisition Address (Figure 13) 

□ Requisition Account Code (Figure 14) 

□ Requisition Summary (Figure 15) 

□ Requisition Confirmation (Figure 16) 
a Requisition Search Criteria (Figure 17) 

□ Requisition Search Result (Figure 18) 
a Requisition Information (Figure 19) 

□ Toolbar (Figure 21) 

□ Change Requester (Figure 22) 



2 



iWebReqs Specification 



(Intentionally left blank) 



iWebReqs Specification 
USE CASE: LOG INTO THE SYSTEM 



Back to the top 

Overview: 

The main purpose of the use case is to log the user into the system as a Requester. The 
user has to exist in the Spectrum Plus database, and must belong to at least one Site. If 
the requester has access to more than one site, the default site (see "Outstanding Issues" - 
[Default Site for the User]) for the requester is used as the working site. If the requester 
has access to only one site, the system will automatically assign the only available site as 
the working site. If the requester is a Site Manager, the [Change Requester] toolbar 
option will be available for changing the requester ID without logging out and re-logging 
in as another requester (see "Outstanding Issues" - [Site Manager]). If the requester is 
considered a New User (see "Outstanding Issues" - [New User]), the system should 
provide a Help Menu to assist the requester after he/she successfully log into the system. 
Otherwise, the system should retrieve and display the Requisition Cart for the requester. 
However, if the user is using the Shared User Account (see "Outstanding Issues" - 
[Shared User Account]) to log in, the system should create a new unique temporary 
Requester for the user. 



Primary Actor: 

Requester 

Starting Point: 

This use case starts when the actor makes a request to log into the system 
Ending Point: 

Login is either successful or the process failed. 
Measurable Result: 

The requester (person_id) is identified and his/her working site (site_id) is also selected. 
Flow of Events: 

A user visits the Login page, enters his/her User ID and Password, and clicks the "Login" 
button. 

The first part of the process is to verify user's identity, validate user's privilege and log 
the user into the system. However, if the user is using a Shared Account, this will take an 
alternate route to use the " Login Using Shared Account " use case. 
The second part of the process is to identify the Working Site for the requester. This 
process uses the " Select a Working Site " use case. 

The third part of the process is to determine whether the requester is a Site Manager. If 
the requester is a Site Manager, the "Change Requester" toolbar option should be made 
available and the site manager can select a different requester on the same site to enter the 
requisition. (See Use Case "Change Requester") 
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The fourth part of the process is to provide assistance to a new user. This process has to 
determine whether the requester is considered a 'new 5 user. If the requester is a new 
user 5 a Help Page is displayed. If the requester is not a new user, the Requisition Cart 
page is displayed. 
[Technical Notes:] 

The system will take the User ID and Password to find a valid entry on the USERS table 
and find the corresponding Person ID. This Person ID will be used to validate the Site 
from the ENTYPERS table. A user must belong to at least one Site. After successfully 
validating the user, person_id will be stored in User Variables (RequesterlD). The 
USERS.iWebReqs_login_count should be incremented by one. This concludes the first 
part of the login process. However, if the user is using a Shared Account, the process 
will continue and use the " Login Using Shared Account " use case. 
The second part of the process uses another use case " Select Working Site " to determine 
the current Working Site for the requester. The result of this process is to obtain the 
site_id. 

The third part of the process is to determine whether the user is a 'new' user and decide 
which page should be displayed after the requester is successfully logged in. If the 
requester is a new user (see "Outstanding Issues"), the system workflow will bring the 
requester to the "New User Help" page. If the requester is not a new user, the system 
workflow will bring the requester to the "Requisition Cart" page. The later case uses the 
use case " Display Requisition Cart" . 

The following information is temporarily stored as session variables specific to the 
logged-in requester (these types of variables will later be referred to as the "User 
Variables"): 

RequesterlD, RequesterName, SitelD, opChangeSite (Y/N, if requester belongs to more 
than one site, it is set to "Y".), opChangeRequester (Y/N, if the requester is a Site 
Manager, it is set to "Y" ), opItemSearch (Y/N, based on Site Configuration setting 
yn_allow_item_search), opltemlnquiry (Y/N, based on Site Configuration setting 
yn_allow_item_inquiry), opReqlnquiry (Y/N, based on Site Configuration setting 
yn_allow_req_search), opViewImage (Y/N, based on Site Configuration setting 
yn_allow_view_image), opUpdateRequester (Y/N, based on Site Configuration setting 
yn_allow_update_requester), opItemRevision (Y/N, based on Site Configuration setting 
yn_allow_item_revision), opSiteManager (Y/N, based on User Role on Site Setup), 
opSharedUser (Y/N, based on users.yn_shared_user), opNewUser (Y/N, based on the 
comparison of users.iwebreqs Jogin_count and System Configuration iWebReqs- 
NewUserCount), opSkipAccount (Y/N, based on System Configuration iWebReqs- 
SkipAccountCode), opValidateRequester (Y/N, based on System Configuration 
iWebReqs-ValidateBasedOnRequester), SiteManagerRequesterlD (same as the 
RequesterlD, if the requester is a Site Manager). 

Alternative Flow of Events: 

If the User ID and Password combination cannot be found on the User table, the Login is 
failed and a corresponding error message should be displayed. 

If the login user does not belong to any Site or the site_id cannot be found on the SITES 
table, the Login has failed and a corresponding error message should be displayed. 
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Related User Interfaces: 

Login (Figure 1) 
About (Figure 2) 
Help Menu (Figure 4) 
Requisition Cart (Figure 6) 

Use Case Extensions: 

None 



Outstanding Issues: 

(All Spectrum Plus changes are now in a separate spec. The information here is just 
for reference.) 
Spectrum Plus Changes: 
[Default Site for the User] 

On the Main Tab of the User Setup window in Spectrum Plus, a new column 
"default_site_id" needs to be added as a drop-down field. This drop-down field should 
populate all available Site ID from the database SITES table. Once selected, the site_id 
should be added to the Site tab available list. This will represent the Default Site for the 
user. However, this is not a required column. If the user is assigned to only one site, the 
only available site will be used as the default site. If the user is assigned to more than one 
site and there is nothing selected from the default site column, the first site on the 
available list is treated as the default site. If the user is not assigned to any site, the user 
will not pass the user validation and hence is not allowed to log in. 
[Site Manager] 

Every logged-in user is a requester and the Person ID is used as the Requester ID. 
However, if the requester is also a Site Manager, meaning that he/she can enter or inquire 
about Requisitions for other requesters on the same site, the Site Manager's Person ID is 
first used to log in by default. The Site Manager can continue to enter requisitions for 
himself/herself and all the default information is based on his/her Requester Profile. 
However, the site manager can "change" to another requester on the same site. (See Use 
Case "Change Requester"). Once a new requester is selected, the Requester ID will be 
changed from the site manager's Person ID to the selected requester's Person ID. And 
then, all the default information is based on this new selected Requester Profile. 
[The "iWebReqs", "ValidateBasedOnRequester" system configuration setting] 
If the setting is set to "OFF" (i.e. "0"), all the default information (Ship-to Address and 
Account Codes) will be based on the Site default. And, the "State/Code" validation is 
based on Site's Address ID. 

If the setting is set to "ON" (i.e. "1"), all the default information will be based on the 
Requester profile. And, the "State/Code" validation is based on Requester's Ship-to 
Address ID. 
[New User] 

On the User Setup window in Spectrum Plus, a new column "iWebReqs_login_count" 
needs to be added as a hidden field with initial value of "zero" (0). A new system 
configuration also needs to be added on the iWebReqs tab "NewUserCount". If the 
USERS. iWebReqs_login_count is less or equal to the value of the system configuration 
"iWebReqs-NewUserCount", this user is considered a "New User". 
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The USERS. iWebReqs_login_count is automatically incremented by one (1) every time 

the user successfully log into the iWebReqs system, except for the Shared User. 

[Shared User Account] 

See " Login Using Shared Account " use case. 

[Application Profile and Database Profile] 

Like S+'s specplus.ini file 5 iWebReqs has an Application Profile named iWebReqs.app. 
This file resides on the X:\Bradley Company\iWebReqs directory on the IIS/MTS server, 
(where X: is the actual path based on customers 5 installation) And, this file is registered 
to the Windows NT Registry. This file currently contains Database Profile information. 
By default, specplus is the database that iWebReqs should connect to and hence a default 
"specplus" database profile is stored in the iWebReqs.app application profile [DB Profile 
- specplus] session. However, for the "Multiple Database" situation, multiple database 
profiles will be stored in iWebReqs.app, for example [DB Profile - customerdbl], [DB 
Profile - customerdb2], etc. The DB Profile name is embedded (hidden field) in the 
Login.asp page (column name: db_jprofile). iWebReqs will use the db_profile value 
provided on the Login.asp page to determine which database profile should be used in 
iWebReqs.app and connect to the database. 
An example of the Application Profile: 
[DB Profile - specplus] 
P r o v i de r = S QLOLEDB 
ServerName=bradpelO 
Database=design240 

([Provider] Note: "SQLOLEDB" for MSSQL, "MSDAORA" for Oracle, and 
"Sybase.ASEOLEDBProvider" for Sybase) 

Database Changes: 
* Users Table: 

Add iWebReqs_login_count column (initial value 0) 
Add default_site_id column 

Related Objects: 

User 

Requester 
Site 
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Back to the top 

Overview: 

The main purpose of the use case is to identify a Working Site for the requester. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester successfully log into the system with the number 
of sites greater than zero. 

Ending Point: 

A Working Site for the requester is identified. 
Measurable Result: 

The Working Site [site_id] is found and stored in the user variable [SITEJD]. 
Flow of Events: 

If the requester belongs to only one site, system will automatically select the site for the 
requester. If the requester belongs to more than one site, the default site on the S+ User 
Setup will be used as the working site. If no default site is set up for a requester, the first 
site on the requester's list of sites in the database will be selected. If the requester would 
like to change to a different working site other than the default site, he/she has to use the 
" Change Working Site" use case to select another site. 

Once the working site is selected the Show/Hide status of all toolbar options for the 
requester should be set based on the Site Configuration Settings (see "Outstanding 
Issues"). These toolbar options are set for each Site. The main reason these 
configuration settings are stored on Site Setup instead of the S+ Window Security is that 
some of these settings have nothing to do with "Window" security (for example: Allow 
View Image, Allow Item Revision, and Allow Item Search). See for Figure 21 the 
Toolbar. 

[Technical Notes:] 

After the requester successfully log into the system a User Variable [opChangeSite] is 
kept during the time the requester remains in the system. 
If [opChangeSite] = 'TNT, the [RequesterlD] is used to get the site_id from the 
ENTYPERS table and validate this sitejd against the SITES table. If [opChangeSite] = 
"Y", the default site for the user USERS. default_site_id should be used and validated 
against the SITE table. If no default site is set up for a requester, the first site on the 
requester's list of sites in the database will be selected. At the end of this process, a 
site_id is identified and stored as a User Variable [SitelD]. 

After a Site ID is identified, the toolbar status has to be adjusted based on each site's 
configuration settings (new settings on S+ Site Setup). These site configurations are to 
determine whether the requester working on this site is allowed to perform the following 
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functions: Item Search, Item Inquiry, Requisition Inquiry, View Image for an item, 
Update Requester Information, and Select Item Revision. 



Alternative Flow of Events: 

If the site_id cannot be found on the SITES table, an error code/message is returned. 

Related User Interfaces: 

None 

Use Case Extensions: 

None 

Outstanding Issues: 

Spectrum Plus Changes: 

* Site Setup Window: 

New Configuration Settings (checkboxes) need to be placed on the Settings tab of the 
Site Setup window. [Allow Item Search?], [Allow Item Inquiry?], [Allow Requisition 
Inquiry?], [Allow Viewing Image for an item?], [Allow Updating Requester 
Information?], and [Allow Selecting Item Revision?]. And, the initial values for these 
columns/checkboxes are "N" (no). 

These checkboxes are available (visible and enabled) if the system configuration "Setup" 
Tab-"iWebReqsSiteConfigON" is turned on. 

* User Setup window: 

Needs to add a User Default Site drop down column. 



Database Changes: 

* Site Table: 

Add yn_allow_item_search column (initial value "Y") 
Add yn_allow_item_inq column (initial value "Y") 
Add yn_allow_req_inq column (initial value "Y") 
Add yn_allow_view_image column (initial value "Y") 
Add yn_allow_update_requester column (initial value "Y") 
Add yn_allow_item_revision column (initial value "Y") 

* Users Table: 

Add default_site__id column (initial value NULL) 
System Configuration Settings: 

Setup Tab: add "iWebReqs_SiteConfigON" - default value '0' (off). 

Related Objects: 

Requester 
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TTSFCASE: CHANGE THE WORKING SITE 




Back to the top 

Overview: 

The main purpose of the use case is for the requester to switch to a different Working Site 
if he/she has access to more than one Site. If the requester belongs to only one site, this 
use case is not accessible. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to switch to a different Working 
Site. 

Ending Point: 

The requester's request to switch to a different Working Site is either completed and the 
requester's Requisition Cart is retrieved and displayed (this process uses the "Display 
Requisition Cart " use case). 

Measurable Result: 

A valid site_id is again assigned and stored as in User Variable [SitelD]. 
Flow of Events: 

A Site Selection page will be displayed and the requester must select a Working Site to 
continue. This use case also needs to get the status of the toolbar and reset all toolbar 
option availability based on the new site configuration (use case "Select Working Site"). 
After successfully selecting a different working site, the requester's Requisition Cart is 
retrieved and displayed. 
[Technical Notes:] 

This Use Case is enabled only if the requester has access to more than one site 
(opChangeSite = "Y"). 

This use case uses the existing use case " Select Working Site" . 

At the end of this process, a site_id is identified and stored as a User Variable. 

Toolbar Status also needs to be adjusted for the site based on the configuration settings 

on Site Setup. . . . 

This use case also uses the " Display Requisition Cart" use case to display the Requisition 
Cart for the requester after switching to another site. 

Alternative Flow of Events: 



Related User Interfaces: 

Change Site (Figure 3) 

Use Case Extensions: 
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Outstanding Issues: 

Once a requester chooses to change to a different Site, he/she no longer has the option to 
"Change Requester" even if he/she is a Site Manager. He/she needs to logout of the 
system and re-login. This rule is used to avoid some security problem. 

Relate Objects: 

Requester 
Site 
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Back to the top 

Overview: 

The main purpose of the use case is to retrieve and display the contents of the Requisition 
Cart for the requester based on his/her REQUESTERJD and SITEJD. 

A Requisition Cart contains Items preselected by the requester and later will be 
used to create a requisition. It is kept in the database identified by the 
REQUESTERJD and the SITEJD. It uses a new database table IWREQCRT 
and consists of sequence jibr, requester Jd, sitejd, itemjd, description, whsejd, 
revjcode, itemjype t qty_requested, uom_requested f image Jink jurl, status, 
comments, segment jyalue J J 2, create Jatetime, and edit_datetime columns. 
Since the Requisition Cart is kept in the database, the requester can log out or 
disconnect from the Internet without losing the items he/she selected. And, when 
the requester log back to the system, his/her Requisition Cart will automatically 
be retrieved and displayed from the database. The requester can add/remove 
items from the Requisition Cart, or choose to empty the entire Requisition Cart. 
Once a requisition is successfully created from the Requisition Cart, the 
Requisition Cart is also emptied by the system. 

For the user who uses a Shared Account to log in, the Requisition Cart will not be 
accessible by the requester once he/she log out of the system because the 
requester will be assigned a new requester Jd every time he/she log into the 
system. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the system or the requester makes a request to display the 
Requisition Cart. 

Ending Point: 

The requester's request to display the Requisition Cart is either completed or the process 
failed. 

Measurable Result: 

The contents of the Requisition Cart for the requester are displayed. 
Flow of Events: 

The system will take the RequesterlD and the SitelD to retrieve all items in the 

IWREQCRT table and display on the Requisition Cart page. 

Viewlmage ItemID Descript. RevCode UOM Qty Update Remove 

Each Item ID field has a hyperlink to open up the Item Detail Information page. This 

will link to the " Display Item Detail " use case. 
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A "View" button is displayed to the left of the Item ID field if the value of the 

rWREQCRT.image_link_url column is not empty. This will link to the "View Image" 

use case. The value of the IWREQCRT.image_link_url is determined in the "Search 

Item" and "Get Image Link" use cases. 

An "Update" button is displayed right next to the UOM column. 

A "Remove" button is displayed at the end of each item line. This will link to the 

" Delete Item from Cart" use case. 

At the top and bottom of the list of items, there should be the following buttons to 

perform extended functions from the Requisition Cart: 

[Back to Previous Item Search Result] [Check Out Now] 

[Add New Item / Search] [Refresh Cart] 

[Empty Req Cart] 

[Back to Previous Item Search Result] will re-display the previously retrieved Item 
Search Result. The "Back to Previous Item Search Result" button will only be displayed 
after a search has been performed. 

[Check Out Now ] will link to the use case "Generate Requisition" . This button should 
only be available if there is at least one item in the Cart. 

[Add New Item / Search] will display the Item Search Criteria page (Use Case: "Search 
an Item" ). 

[Refresh Req Cart] will re-retrieve the Requisition Cart. 

[Empty Req Cart] will reset/empty the requester's Requisition Cart (Use Case: "Empty 
Req Cart" ) 

Related User Interfaces: 

Requisition Cart (Figure 6) 

Alternative Flow of Events: 

If the process failed to retrieve the contents of the Cart, a corresponding error message 
should be displayed. 

Use Case Extensions: 
None 

Outstanding Issues: 
[Database Changes:] 
New table IWREQCRT: 
See database schema for detail. 

Related Objects: 

REQCart 
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USE CASE: SEARCH AN ITEM 

Back to the top 

Overview: 

The main purpose of the use case is for the requester to search for an Item. Before the 
requester adds any items to the Requisition Cart, the requester has to search for the item 
if he/she either does not know the full Item ID or wants to verify the item information. 
This use case is used by the " Add Item to the Cart" use case. However, items may not be 
accessible to (cannot be seen by) the requester because (a) items do not meet the 
State/Code validation for the site he/she is working on, (b) items do not associate to the 
warehouses he/she belongs to, (c)* items are not requisitionable, or (d) items are 
restricted by customer's special validation rules. The validation for item's accessibility 
will use the " Item Validation - Item Accessibility" use case. 

*Note on (c): An item cannot be requisitioned because either the "Requisition" checkbox 
on Item Setup is unchecked (item.yn_allow_req), or it has an Item Type where the 
"Allow Requisition" checkbox on the Transaction tab of Item Type Setup is unchecked 
(itemtype.yn_allow_req). 



Primary Actor: 

Requester 

Starting Point: 

This use case starts when the actor makes a request to search for an Item. 



Ending Point: 

The actor's request to search for an item is either completed or the process failed. 
Measurable Result: 

The Item the requester is searching for is displayed on the search result page. 
Flow of Events: 

The requester will first see the Item Search Criteria page that consists of the Item ID, 

Description, Commodity, Coordinator Name, and Item User Fields 1-4 columns. 

Note: The Friendly Fields for the User Fields on this page must be set up in the Spec Plus 

System Configuration window on the iWebReqs tab under the following settings: 

FF ITEM UF1 , FF_ ITEM _UF2, FF_ ITEM _UF3, FF_ ITEM _UF4. 

The values in the User Fields use the same codes as Spectrum Plus: ITEMUSR01, 

ITEMUSR 02, ITEMUSR 03, ITEMUSR04. 

The Commodity, Coordinator Name and User Fields are non-editable drop-down list 
boxes that already have data populated by the system. Item ID-and Description will 
allow the requester to type in partial text to search for all matches using radio buttons: 
"Starts With", "Contains", "Ends With". The default setting for the Item ID radio buttons 
is "Starts With". The default setting for the Description field is "Contains". Once the 
requester fills in the criteria on any one of the fields and clicks on the "Search" button, 
the system will try to retrieve all items that match the criteria. The "Starts With" radio 
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button allows users to search using a set of consecutive characters at the beginning of an 
item ID or description. The "Contains" radio button allows users to search using a set of 
consecutive characters that are within an Item ID or description. The "Ends With" radio 
button allows users to search with a set of consecutive characters that appear at the end of 
an item ID or description. The "Equals" radio button allows users to search using an 
exact match of a set of characters. 

However, the "Item Validation - Item Accessibility" use case should be performed here 
to filter out items that should not be seen by the requester. 

Items that (a) don 't meet the state/code validation, or 

(b) don 't belong to a warehouse that the requester has access to, or 

(c) are not requisitionable, or, in a later release: 

(d) don 't meet customer's special restriction rules will be eliminated from the list. 
All items matching the above criteria are the search result. However, if any item is 
"obsolete" but with Replacement Item or is a regular item but with Substitute Item, its 
Replacement/Substitute Item should also be added to the search result directly below the 
original item. 

The final result is a list of Items displayed in a tabular format on the Item Search Results 
page. This final search "Result Set" should be saved in the IWITMSRH database table. 
The IWITMSRH table can be used to re-display the Item Search result from the "Display 
Requisition Cart " use case after adding an Item to the Requisition Cart (Use Case: "Add 
Item to Cart" ). Each Item ID value will have a hyperlink to display detail Item 
information (Use Case: " Display Item Detail" ). 

If the item has a viewable image associated (Use Case: " Get Image Link "), a "View" 
button should be displayed right next to the Item ID column (Use Case: "View an 
Image "). 

Description, Distribute UOM and an editable Qty Request column (default value 1) 
should also be displayed. At the end of each record, an "Add to Cart" button should be 
displayed (Use Case: " Add Item to Cart" ). 

Viewlmage ItemID Description QtyRequest Distribut eUOM AddToCart 
Note 

The Note field will display information that an item is a Replacement or Substitute of the 
item directly above. A small arrow will also be displayed to direct the user to the item 
above. 

Alternative Flow of Events: 

If the requester does not enter any value in a criteria column, a message should be 
displayed. 

If the search returns nothing, a message should be displayed telling the user that nothing 
was found matching the entered criteria. A blank page should not be displayed. 
Items that are obsolete and have a replacement item will be displayed without a Qty input 
field or an "AddToCart" button. 

Related User Interfaces: 
Item Search Criteria (Figure 7) 
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Item Search Result (Figure 8) 
Item Information (Figure 9) 
View Image (Figure 10) 
Item Revision (Figure 1 1) 

Use Case Extensions: 

None 

Outstanding Issues: 

None 

Related Objects: 

ItemSearch 
Item 

ItemValidationAccessiblity 

Site 

User 

Requester 
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USE CASE: ITEM VALIDATION - ITEM ACCESSIBILITY 

Back to the top 

Overview: 

The main purpose of the use case is to validate item's accessibility to make sure that the 
requester cannot access (see) items that are not accessible to him/her. Items that don't 
meet the state/code validation, or don't belong to a warehouse that the requester has 
access to, or are not requisitionable, or don't meet customer's special restriction rules will 
be eliminated from the list. 

Primary Actor: 

Requester 

Starting Point: 

This use case will be used by other use cases. This use case will receive a list of items to 
start the process. 

Ending Point: 

The request to eliminate items that are not accessible to the requester is either completed 
or the process failed. 

Measurable Result: 

A list of items is returned to the original source (use case). 
Flow of Events: 

If the "iWebReqs", "ValidateRequester" system configuration setting is set to "1", the 
State/Code validation is based on Requester's Ship-to Address ID. Otherwise, the 
State/Code validation is based on Site's default Address ID. 

First, the system will get a list of warehouses that the requester belongs to and a list of 
states and codes that are assigned to either the Site, or to the Requester's Ship To 
Address. For each item in the list the system will also get a list of warehouses that the 
item belongs to, and a list of states and codes that are assigned to the item. The system 
will then compare the requester's warehouse list to the item's warehouse list. If there is 
no match between these two lists, the item will be eliminated from the list. If the 
warehouse validation passes, the system will compare the item's States and Codes with 
either the Site's States and Codes or the States and Codes belonging to the Requester's 
Ship To Address. If there is no match between the States and Codes of then item and 
either the Site or Address, the item will also be eliminated from the list. 

Also, if the item is not requisitionable, it should be eliminated from the list too. An item 
cannot be requisitioned because either the "Requisition" checkbox on Item Setup is 
unchecked (item.yn_allow_req = "N"), or it has an Item Type where the "Allow 
Requisition" checkbox on the Transaction tab of Item Type Setup is unchecked 
(itemtype.yn_allow_req = "N"). 

Furthermore, if the customer has any special restriction rules for the item accessibility, 
additional validation rules can be customized and applied here. 
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After the list of valid items is created, a search should be performed for each item. If an 
item has a replacement or substitute item set up 5 the replacement or substitute item should 
be retrieved and validated using the previously mentioned warehouse and States/Codes 
validation processes. If a replacement item or substitute item is found to be valid to the 
requester, it should be displayed immediately after the original valid item to which it 
belongs. However, obsolete items with replacements cannot be added to the Requisition 
Cart. 

(Hence, the requester can decide to choose the original item or its substitute. And, the 
Item Status validation can simply ignore the case of recursively validating the 
Replacement/ Substitute item.) 

[Technical Note:] The system will call the USER object to get a list of accessible 
warehouse [once], call SITE object to get a list of valid states/codes [once], call ITEM 
object to get a list of states/codes [multiple], and call ITEMVALIDATIONCUSTOM to 
perform customer special validation. 

Alternative Flow of Events: 

If the system encounters an error obtaining any list and hence fails to perform the 
validation, a corresponding error message should be displayed and an empty item list 
should be returned. 

If the system encounters an error while performing the custom validation rule, a 
corresponding error message should be displayed and an empty item list should be 
returned. 

Related Objects: 

User 

Site 

Item 

ItemSearch 

ItemValidationAccessiblity 

Related Interfaces: 

None 

Use Case Extensions: 

None 

Outstanding Issues: 

None 



21 



iWebReqs Specification 
USE CASE: DISPLAY ITEM DETAIL INFORMATION 



Back to the top 

Overview: 

The main purpose of the use case is to display detail information about an Item. In the 
first release, the information will be very similar to the information on the bottom part of 
the Spectrum Plus Requisition Entry Detail tab will be displayed. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to display Item Detail 
Information by clicking on an Item ID hyperlink. 

Ending Point: 

The requester's request to see Item Detail is either completed or the process failed. 
Measurable Result: 

An Item Detail page is displayed. It will have the same information from the bottom 
screen of the S+ Requisition Detail tab. 

Flow of Events: 

When a user clicks on the Item ID hyperlink on the Req Cart page or on the Item Search 
Results page, the Item Detail page will be displayed. The following columns will appear: 
View Item (button), Item ID, Description, Qty (input), UOM, Add to Cart (button), 
Coordinator ID/Name, Coordinator Phone, Commodity, Item Type, Qty in Pickable Bins, 
Total Qty on Order, Expected Delivery Date, Qty Committed, Last Package Qty, Qty 
Available, Restricted y/n, Restriction Notes. 

The View Item icon/button will appear only if the opViewImage value = T for the 
current Site. 

The values/quantities for the columns listed above should be the sums of all quantities in 
all warehouses where the item is set up. 

Users get to this page by clicking on an Item ID, which is a link to this page. If users 
come from the Requisition Cart page, there will not be a Qty (input) field or an Add to 
Cart (button). (This is because the item is already in the Cart.) Also, these two fields will 
not be displayed if the user comes from the Item Search Results page, and the item is 
obsolete with a replacement item. The user cannot requisition an obsolete item if it has a 
replacement. 



Related User Interfaces: 

Item Information (Figure 9) 

Alternative Flow of Events: 

None 
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Use Case Extensions: 

None 

Outstanding Issues: 
None 

Related Objects: 

ItemSearch 
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USE CASE: GET IMAGE LINK 

Back to the top 

Overview: 

The main purpose of the use case is to obtain the link (the URL) to the image associated 
to the item. An item may or may not have a viewable image associated with it. 

Primary Actor: 

Requester 

Starting Point: 

This use case is used by other use cases. This use case will receive an Item ID from other 
use cases. 

Ending Point: 

The request to obtain the image link is either completed or the process failed. 
Measurable Result: 

If there is no viewable image associated to the item, an empty string array will be 
returned. 

If there is one or more than one image links for the item, a string array will be returned. 
Flow of Events: 

This use case will take the Item ID and retrieve links from the ITEMLINK table. Only 
the links associated to the iWebReqs module will be returned. If there is only one link 
returned, this link (an URL) will be used and embedded into the View button. If more 
than one links are returned, the first one is chosen. 

Alternative Flow of Events: 

If the system fails to perform this process, an empty string array is returned. 

Related Objects: 

Item 



Related Interfaces: 

None 

Use Case Extensions: 

None 

Outstanding Issues: 

Refer to new spec for "Item Link" feature in Spectrum Plus. 
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USE CASE: VIEW AN IMAGE/FORM 

Back to the top 

Overview: 

The main purpose of the use case is to display the image associated to the Item in the 
browser when the requester clicks on the "View" button next to the Item ID. If the item 
does not have any viewable image associated with it, the "View" button won't be 
available to the requester. The availability of the viewable image and the visibility of the 
4 View" button are handled on the " Item Search " Use Case and the " Get Image Link " use 
case. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to view the image associated to 
the item. 

Ending Point: 

The requester's request to view the image for the item is either completed or the process 
failed. 

Measurable Result: 

A separate browser instance should be opened to display this page. If the image is a PDF 
image, the Adobe Acrobat Plug-in for the browser is required. 

Related User Interfaces: 

View Image (Figure 1 0) 

Flow of Events: 

If the item has a viewable image associated with it, while doing the Item Search, the 
hyperlink to the image is already added to the 4 View" button. When clicking on the 
"View" button, the requester is simply making a HTTP request to the image source file 
and open up a separate browser instance to display the image. 

Alternative Flow of Events: 

If the image is not available (has been moved) or the required image viewer is not 

installed correctly, the browser will display a corresponding message, 
i 

Use Case Extensions: 

None 

Outstanding Issues: 

None 

Related Objects: 

Item: 
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ItemSearch: 
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TTSF CASE: ADD ITEM TO THE CART 




Back to the top 



Overview: 

The main purpose of the use case is to add an item to the Requisition Cart. After 
successfully searching and identifying the item on the Item Search Result page, the 
requester can choose to add the item to the Requisition Cart by entering the Quantity 
Request and then clicking on the "Add to Cart" button. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the actor makes a request to add an item to the Requisition Cart 
from the Item Search Result page or the Item Information page. 

Ending Point: 

The actor's request to add the item to the Requisition Cart is either completed or the 
process failed. 

Measurable Result: 

The Item is added and displayed on the Requisition Cart page. 
Flow of Events: 

In order to successfully add an item to the Requisition Cart, the requester has to specify 
the Quantity Requested (or accept the default value "1") and the Item has to pass all Item 
Status validations. After an Item is successfully added to the Cart, the Requisition Cart 
should be displayed (Use Case: " Display Requisition Cart" ). 

There is no need to perform the state/code or warehouse/item validation because these 
validations are done during the item search process (use case "Search Item"). 
Even if the requester knows exactly which item to add to the Requisition Cart, he/she still 
first needs to enter the Item ID in the Item Search Criteria page (Use Case: "Search an 
Item" ) to make sure that the item does exist and that it is accessible to the requester (Use 
Case: " Item Validation - Item Accessibility" ). 

If the item is already in the Cart, it is not allowed to be added to the Cart again. 
After clicking on the "Add to Cart" button, all Item Status Validations (Use Case: "Item 
Validation - Item Status" ) should be done at this point. There is no need to perform the 
state/code or warehouse/item validation because these are done during the item search 
(Use case " Search Item" ). However, an item-warehouse association needs to be made in 
the database in order to save. The user's default wareshouse will first be checked to see if 
the item is associated with that warehouse. If the item is not set up in that warehouse, the 
system will then check the user's other warehouses and select the first one that has the 
item set up in it. 

If the item has more than one revision, all available revision codes should be displayed on 
the Item Revision page for the requester to pick which revision he/she would like to 
request. This Revision Selection function can be turned off based on the Site 
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Confi guration y n_allow_revision. The "*" revision should be also be displayed so that it 
is available to requesters. 

If the item has no revision setup, the default "*" revision is used. 
Alternative Flow of Events: 

If the validation failed, the corresponding message should be displayed based on the 
" Item Validation - Item Status" use case. 

Related User Interfaces: 

Item Search Result (Figure 8) 
Item Information (Figure 9) 
Requisition Cart (Figure 6) 
Item Revision (Figure 1 1) 

Use Case Extensions: 

None 

Outstanding Issues: 

None 

Related Objects: 

Item 

ItemValidateStatus 
Site 

REQCart 
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USE CASE: ITEM VALIDATION - ITEM STATUS 

Back to the top 

Overview: 

The main purpose of the use case is to perform Item Status validation. The item can be 
an Obsolete Item, a Limited Item, a Restricted Item, a PrintLink Item, a Non-Manually- 
Selected Serial-Number Item, or a Standard Kit Item. However, a Nonstock item (item 
not set up in the database), a Manually-Selected Serial-Number Item, a Dynamic Kit 
Item, a Misc. Item, or One-time PrintLink item will not be allowed in the first release. 

Primary Actor: 

Requester 

Starting Point: 

This use case will be used by other use cases. This use case will receive an Item ID from 
other use cases. 

Ending Point: 

The item is either valid or not valid for requisition. 

Measurable Result: 

The validation result is returned. 

Flow of Events: 

The Item Status Validation Rules are described below: 

(There is no need to consider the Replacement or Substitute item because it has been 
done in the Item Accessibility Validation use case.) 

Obsolete Item : If the item is obsolete, give an "Obsolete" warning message to allow the 
requester to decide whether or not to add this item. 
Limited Item : Always valid but a warning message needs to be displayed. 
Restricted Item : Always valid but a warning message needs to be displayed. 
PrintLink Item : Always valid. (If the item is not in an accessible Digital Warehouse, it 
will not pass the Item Search.) 

Non-Manuallv-Selected Serial-Number Item : If the item is not designated as being a 
Manually-selected Serial Number item (item.yn_serial_manual = l N'), it can be 
requisitioned in this application. The item will be treated like a regular stock item. No 
further functions will be available in this release. 

Standard Kit Item : Standard kit can be requisitioned like a regular stock item, but further 
functions are not available in the first release. Dynamic kits cannot be requisitioned in 
this release. 

Maximum Requisition Quantity : If the qty requested is greater than the max REQ qty of 
the item, a message which indicates the max REQ qty value will be displayed to the user 
and the user CANNOT requisition for that item. In other words, there will be no choices 
for the user to choose from, they have to re-enter the qty requested. 
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Alternative Flow of Events: 

If the item fails the validation, the corresponding message should be displayed to reject 
the item from being added to the Requisition Cart. 

Related Objects: 

Item 

REQCart 

ItemValidateStatus 

Related Interfaces: 

None 

Use Case Extensions: 

None 

Outstanding Issues: 

None 
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Back to the top 

Overview: 

The main purpose of the use case is to delete an item from the Requisition Cart. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to remove an item from the 
Requisition Cart. 

Ending Point: 

The actor's request to remove an item from the Requisition Cart is either completed or 
the process failed. 

Measurable Result: 

The item to be deleted no longer appears in the Requisition Cart. 
Flow of Events: 

On the Requisition Cart page (Use Case: " Display Requisition Cart" ), the requester can 
click on the "Remove" button at the end of each Item Line to take the item out of the 
Requisition Cart. The hidden column "Sequence ID" is used to perform the deletion on 
the IWREQCRT table. A Yes/No warning message will appear asking the user if he/she 
wants to delete the item. After the deletion, the Requisition Cart is refreshed (Use Case: 
"Dis play Requisition Cart" ). 

Alternative Flow of Events: 

If the deletion encounters any system error, a message describing the system error should 
be displayed and then the requester will select the "Back to the Requisition Cart" button 
to refresh/re-display the Requisition Cart. 

Related User Interfaces: 

Requisition Cart (Figure 6) 

Use Case Extensions: 

None 

Outstanding Issues: 

None 

Related Objects: 

REQCart 
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USE CASE: EMPTY THE CART 

Back to the top 

Overview: 

The main purpose of the use case is to empty the entire Requisition Cart. All items in the 
requester's Requisition Cart should be removed. 



Primary Actor: 

Requester 



Starting Point: 

This use case starts when the requester makes a request to empty the Requisition Cart. 



Ending Point: 

The requester's request to empty the Requisition Cart is either completed or the process 
failed. 

Measurable Result: 

The Requisition Cart is emptied and all items in the requester's Requisition Cart are 
removed (the page is refreshed with no item in the Requisition Cart). 

Flow of Events: 

When the requester clicks on the "Empty Cart" button on the Requisition Cart page (Use 
Case: " Display Requisition Cart" ), the system should delete all items that are associated 
with the requester/site combination (REQUESTER JD, SITEJD) from the IWREQCRT 
table. A Yes/No warning message will appear asking the user if he/she wants to empty 
the contents of the Cart. After the deletion, the Requisition Cart is refreshed (Use Case: 
" Display Requisition Cart ") and should be empty. 

Alternative Flow of Events: 

If the deletion encounters any system error, a message describing the system error should 
be displayed and then the requester will select the "Back to the Requisition Cart" button 
to refresh/re-display the Requisition Cart. 



Related User Interfaces: 

Requisition Cart (Figure 6) 

Use Case Extensions: 

None 

Outstanding Issues: 

None 

Related Objects: 
REQCart 
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USE CASE: GENERATE A REQUISITION 

Back to the top 

Overview: 

The main purpose of the use case is to generate a requisition based on all items in the 
requester's Requisition Cart. The system needs to collect Requisition information such 
as Requisition Header, Requester Address, and Requisition Account Codes before saving 
the requisition. All items in the requester's Requisition Cart will be transferred to 
become Requisition Line Items. 



Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to generate a requisition based on 
his/her Requisition Cart. 

Ending Point: 

The requester's request to generate a requisition is either completed or the process failed. 
Measurable Result: 

A new requisition is created with a new Requisition Number, all items in the requester's 
Requisition Cart become requisition line items, and the requester's Requisition Cart is 
emptied and the Requisition Confirmation page is displayed. 

Flow of Events: 

On the Requisition Cart page, the requester selects to generate a requisition based on the 
items in his/her Requisition Cart. The requester will navigate through the wizard style 
Requisition Entry pages (Requisition Header page, Requisition Address page, Requisition 
Account Codes page, Requisition Summary page, and Requisition Confirmation page). 

■ When the requester clicks on the "Check Out" button, the system will initially set 
these User/Session variables to "N" - HasREQSHEAD, HasREQSADDR, and 
HasREQSACCT. 

■ While the requester navigates through the Requisition pages, the system will 
temporarily store all of the values on each page back into database tables based on 
RequesterlD and SitelD IWREQHEA table (for Requisition Header), IWREQADD 
table (for Requisition Address) and IWREQACC table(for Requisition Account 
Codes). 

■ On the Requisition Header page, if the User Variable [HasREQSHEAD] is "N", the 
Requisition Header page should have the following columns with initial values: 

o Requisition Date (editable, default Today/Now), 

o Date Needed (editable, value from system configuration setting: Requisition Tab: 
DefaultDateExpectedDays.)(This corresponds to the "Date Expected" in Spec 
Plus. However, only the Date will be displayed - not the date and time.), 
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d Shipment Method - should default in with the value in the System Configuration 

setting "ReqDefaultShipMethod" (dropdown list box from CODE table), 
o REQ Source (hidden, value: "iWebReqs"), 
o Site ID (hidden, value: User Variable [SITEJD]), 
o Structure ID (hidden, value from company_id and COMPANY table), 
o Requester Name (disabled, value: User Variable [REQUESTER_NAME]), 
o Address ID (hidden, from either the Requester, if the system configuration 

"IWebReqs", "ValidateRequester" is turned ON; or otherwise, from the Site), and 
o User Fields 1 -4 (editable), The values in the User Fields on the Requisition 

Header page use the same codes as Spectrum Plus: REQHUF01, REQHUF02, 

REQHUF03, REQHUF04. 
o Comments (editable). 

However, if the User Variable [HasREQSHEAD] is "Y", all values from 
IWREQHEA table for the RequesterlD and SitelD combination should be put back to 
the columns on the page. 

■ On the Requisition Address page, if the User Variable [HasREQS ADDR] is "N", 

o if the system configuration "iWebReqs", "ValidateBasedOnRequester" is turned 
ON, the requester's default Ship-to Address should be defaulted here. If the 
requester does not have a default Ship-to Address, the default Ship-to Address 
from the site (ENTYADDR table) should be defaulted. If neither exists, leave all 
address columns blank. 

o if the system configuration "iWebReqs", "ValidateBasedOnRequester" is turned 
OFF, the site's default Ship-to Address should be defaulted here. 

However, if the User Variable [HasREQSADDR] is "Y", all values from 

IWREQADD table for the RequesterlD and SitelD combination should be put back to 

the columns on the page. 

■ On the Requisition Account Codes page, if the User Variable [HasREQSACCT] is 
«N", 

o if the system configuration "iWebReqs", "ValidateBasedOnRequester" is turned 
ON, the requester default Account Codes should be defaulted here. If the 
requester does not have default Account Codes, the default Account Codes from 
the site (SITES table) should be defaulted. If neither exists, leave all account 
code columns blank. 

o if the system configuration "iWebReqs", "ValidateBasedOnRequester" is turned 

OFF, the site's default Account Codes should be defaulted here. 
However, if the User Variable [HasREQSACCT] is "Y", all values from 
IWREQACC table for the RequesterlD and SitelD combination should be put back to 
the columns. 

The Account Code Structure should use the Structure ID on IWREQHEA table for 
the RequesterlD and SitelD combination. 

Also, if a Segment is restricted (yn_restricted_N = "Y") (from either 
persacct.yn_restricted_N or sites.yn_restricted_N, based on iWebReqs- 
ValidateBasedOnRequester), the segment value should be displayed but not editable. 
This page can be skipped if the "iWebReqs", "SkipAccountCode" system 
configuration setting is set to "1". 
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■ On the Requisition Summary page, the requester will be able to review the entire 
requisition information before committing to generating the requisition. At this point, 
a new requisition number is still not generated. This page should display all 
information from the following tables: IWREQHEA, IWREQADD, IWREQACC, 
and rWREQCRT for the combination of RequesterlD and SitelD. 

■ The requester can then click on the "Submit Requisition" button to commit (update to 
database) the whole transaction. A new requisition number is then generated and all 
data are inserting into requisition tables reqshead, reqsaddr, reqsacct, reqsitem and 
pickpend tables. The System will also clear out data in the following tables 
IWREQHEA, IWREQADD, IWREQACC, and IWREQCRT for the combination of 
RequesterlD and SitelD. The system will then display the Requisition Confirmation 

P a g e - . . 

■ On the Requisition Confirmation page, all previously updated information is re- 
displayed/retrieved in a printable format. The requester can print this page as a 
confirmation record. 

■ The Ship To Address page, the Acct Code page and the Summary page will all have a 
"Cancel and Return to REQ Cart" button. This will return the user to the Req Cart 
page and delete any information that was entered or changed on the Req Header, Ship 
To Address and Acct Codes pages. These three pages will revert back to their default 
values. 

Alternative Flow of Events: 

■ If the database update encounters system error, a message should be displayed and 
allow me user to return back the Requisition Cart page. 



Related User Interfaces; 

Requisition Cart (Figure 6) 
Requisition Header (Figure 12) 
Requisition Address (Figure 13) 
Requisition Account Code (Figure 14) 
Requisition Summary (Figure 15) 
Requisition Confirmation (Figure 16) 

Use Case Extensions: 

None 

Outstanding Issues: 

None 

Related Objects: 

REQCart 

Requisition 

Requester 

Site 

AccountCode 
Code 
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USE CASE: SEARCH A REQUISITION 

Back to the top 

Overview: 

The main purpose of the use case is to search for a requisition and inquire about its 
related status/information. If the requester is a Site Manager, he/she can inquire about 
those requisitions that are entered from the same Site. Otherwise, the requester can only 
inquire about those requisitions that are entered using the same requester ID under which 
he/she is logged in. However, if the requester is a Shared User, the only Search option 
available to the Shared User is the Requisition Number. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to search for/inquire about a 
requisition. 

Ending Point: 

The requester's request to search for a requisition is either completed or the process 
failed. 

Measurable Result: 

The requisition is found and displayed. 

Flow of Events: 

When the requester selects to inquire about a requisition by clicking on the "Requisition 
Inquiry" toolbar option, the Requisition Inquiry Criteria page is displayed with the 
following columns: 

Requisition Number (the field is editable, but no search is available for the field) (Note: a 
requester does not have to enter leading zeros.), 

Requester (If the requester is a Site Manager, a drop-down list will be visible showing 
only the requesters associated with the current Site; otherwise, a disabled/display-only 
Requester ID will be displayed), 

Date Range (From Date and To Date) on requisition date (editable, Date field)(The "To 
Date" will display today's date by default. The "From Date" will initially display a date 
one month prior to today's date.)(Valid date formats are: MM/DD/YY, MM/DD/YYYY, 
MM-DD-YY, MM-DD-YYYYY. Either a "/" or "-" is accepted by the system.) 
and 

Header Status (drop-down, values: "Open", "Closed", "Partial"). The search result will 
display a list of Requisitions in a tabular format with these columns: Requisition 
Number, Status, Requester, Date Requested, and Date Shipped. This list is temporarily 
stored in the IWREQSRH table for the RequesterlD and SitelD combination. 
The Requisition Number field has a hyperlink to open a Requisition Detail page to 
display the following information for each requisition: 
o Requisition Header, 
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o Ship-to Address, 
o Header Account Codes, 
o Header User Fields and Comments 
o Requisition Items and their status, 
o Shipping Charges. 

Note: The Friendly Fields for the User Fields on this page must be set up in the Spec Plus 
System Configuration window on the iWebReqs tab under the following settings: 
FF_REQ_UF1, FF_REQ_UF2, FF_REQ_UF3, FF_REQ_UF4. 

Alternative Flow of Events: 

If the search returns nothing, a message should be displayed telling the user that nothing 
was found matching the entered criteria. A blank page should not be displayed. 

Related User Interfaces: 

Requisition Search Criteria (Figure 17) 
Requisition Search Result (Figure 18) 
Requisition Information (Figure 19) 

Use Case Extensions: 

None 

Outstanding Issues: 
None 

Related Objects: 

REQSearch 
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USE CASE: MODIFY REQUESTER INFORMATION 




Back to the top 

Overview: 

The main purpose of the use case is to allow the requester to modify/update his/her 
personal information, E-mail Address, Default Ship-to Address and Phone Number 
(including Area Code, Phone Nbr, Extension, Access Code and Coutnry Code), and 
Default Account Codes. 

The user can change the Account Codes, but they will be restricted based on the Person's 
restrictions on the Acct Codes tab of the Person Setup window 
(persacct.yn_restrict_seg_l - 12). 

The Administrator will set up person profile, including Account Codes and their 
restriction, in S+ Person Setup. If the Administrator think the requester should not be 
allowed to change the Account Code on any particular segment, Admin will check the 
check box to restrict that. Hence, we should use that restriction on the "Change Requester 
Info" page to follow the same idea. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to modify/update his/her personal 
information. 

Ending Point: 

The requester's request to modify/update his/her personal information is either completed 
or the process failed. 

Measurable Result: 

The requester's personal information is updated. 
Flow of Events: 

When the requester selects the toolbar option "Change User Info", the Requester 
Information page should be displayed and all information should be retrieved and 
editable. The requester can then click on the "Save Changes" button to commit the 
changes. 

Alternative Flow of Events: 

If the update encounters any system error, a corresponding message should be displayed. 

Use Case Extensions: 

None 

Outstanding Issues: 
None 
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USE CASE: CHANGE REQUESTER 

Back to the top 

Overview: 

The main purpose of the use case is to allow the Site Manager to enter requisition for 
another requester on the same site. This use case is only available to the Site Manager. 



Primary Actor: 

Requester 

Starting Point: 

This use case starts when the requester makes a request to change to a different requester. 
Ending Point: 

The requester's request to change to a different requester is either completed or the 
process failed. 

Measurable Result: 

The current Requester ID (Person ID) is changed and a new Requisition Cart is retrieved 
for the new selected Requester ID. The User variables RequesterlD and RequesterName 
will be updated. 

Flow of Events: 

When the requester selects the toolbar option "Change Requester", a list of Requester on 
the same site should be displayed ("Requester Name"). The requester can select a 
requester from the list. 

Alternative Flow of Events: 

Use Case Extensions: 

None 

Related User Interfaces: 

Change Requester (Figure 22) 

Outstanding Issues: 

Once a requester chooses to change to a different Requester, he/she no longer has the 
option to "Change Site" even if he/she has access to more than one site. He/she needs to 
logout of the system and re-login. This rule is used to avoid some security problem. 

Related Objects: 

Requester 
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Back to the top 

Overview: 

The main purpose of the use case is to log the requester out of the system and bring the 
focus back to the Login page. 

Primary Actor: 

Requester 

Starting Point: 

This use case starts when the actor makes a request to log out of the system by clicking 
on the Toolbar option "Logout". 

Ending Point: 

The actor's request to log out of the system is either completed or the process failed. 
Measurable Result: 

The requester is brought back to the Login page and all User Variables should be cleared. 
Flow of Events: 

When the requester clicks on the Toolbar option "Logout", the system should ignore all 
current function and bring the requester back to the Login page. And 5 if the requester is a 
temporary requester (created from the shared account), this temporary requester should 
be deleted (use case " Shared Account" ). However, before doing that, the system should 
make sure that all User Variables should be reset. 



Alternative Flow of Events: 



Use Case Extensions: 

None 

Outstanding Issues: 

None 
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Figure 1 : Login 
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Figure 2: About 
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User Interface: CHANGE SITE 
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User Interface: HELP MENU 
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Figure 4: Help Menu 



47 



iWebReqs Specification 



User Interface: UPDATE REQUESTER INFO 
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Figure 5: Update Requester Info 
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Figure 6: Requisition Cart 
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User Interface: ITEM SEARCH CRITERIA 
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User Interface: ITEM INFORMATION 
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Figure 9: Item Information 



52 



iWebReqs Specification 
User Interface: View Image 
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Figure 10: View Image 
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Figure 11: Item Revision 
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Figure 12: Requisition Header 
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Figure 13: Requisition Address 
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Figure 14: Requisition Account Code 
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Figure 15: Requisition Summary 
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Figure 16: Requisition Confirmation 
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Figure 17: Requisition Search Criteria 
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Figure 18: Requisition Search Result 
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Figure 19: Requisition Information 
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Figure 21 Toolbar 
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Figure 22 Change Requester 
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